Tailscale Overview

Introduction

Tailscale is a mesh VPN built on WireGuard. It provides secure connectivity between devices without requiring a traditional hub-and-spoke VPN concentrator for day-to-day traffic. In practice, it is often used to reach homelab services, administrative networks, remote workstations, and private developer environments.

Purpose

The main purpose of Tailscale is to make private networking easier to operate:

• Identity-based access instead of exposing services directly to the internet
• Encrypted device-to-device connectivity
• Simple onboarding across laptops, servers, phones, and virtual machines
• Optional features for routing subnets, advertising exit nodes, and publishing services

Architecture Overview

Tailscale separates coordination from data transfer.

• Control plane: devices authenticate to Tailscale and exchange node information, keys, policy, and routing metadata
• Data plane: traffic is encrypted with WireGuard and sent directly between peers whenever possible
• Relay fallback: when direct peer-to-peer connectivity is blocked, traffic can traverse DERP relays

Typical flow:

Client -> Tailscale control plane for coordination
Client <-> Peer direct WireGuard tunnel when possible
Client -> DERP relay -> Peer when direct connectivity is unavailable

Important components:

• Tailnet: the private network that contains your devices and policies
• ACLs or grants: rules that control which identities can reach which resources
• Tags: non-human identities for servers and automation
• MagicDNS: tailnet DNS names for easier service discovery
• Subnet routers: devices that advertise non-Tailscale LAN routes
• Exit nodes: devices that forward default internet-bound traffic

Core Concepts

Identity first

Tailscale access control is tied to users, groups, devices, and tags rather than only source IP addresses. This works well for environments where laptops move between networks and services are distributed across cloud and on-prem hosts.

Peer-to-peer by default

When NAT traversal succeeds, traffic goes directly between devices. This reduces latency and avoids creating a permanent bottleneck on one VPN server.

Overlay networking

Each device keeps its normal local network connectivity and also gains a Tailscale address space. This makes it useful for remote administration without redesigning the entire local network.

Configuration Example

Install and authenticate a Linux node:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
tailscale status

Advertise the node as infrastructure with a tag:

sudo tailscale up --advertise-tags=tag:server

Operational Notes

• Use ACLs or grants early instead of leaving the entire tailnet flat
• Use tags for servers, containers, and automation agents
• Prefer MagicDNS or split DNS over hard-coded IP lists
• Treat subnet routers and exit nodes as infrastructure roles with extra review

Troubleshooting

Device is connected but cannot reach another node

• Check whether ACLs or grants allow the connection
• Confirm the target device is online with tailscale status
• Verify the service is listening on the expected interface and port

Traffic is slower than expected

• Confirm whether the connection is direct or using DERP
• Inspect firewall and NAT behavior on both sides
• Check whether the path crosses an exit node or subnet router unnecessarily

DNS names do not resolve

• Verify MagicDNS is enabled
• Check the client resolver configuration
• Confirm the hostname exists in the tailnet admin UI

Best Practices

• Use identity-based policies and avoid broad any-to-any access
• Separate human users from infrastructure with groups and tags
• Limit high-trust roles such as subnet routers and exit nodes
• Document which services are intended for tailnet-only access
• Keep the local firewall enabled; Tailscale complements it rather than replacing it

References

• Tailscale: What is Tailscale?
• Tailscale: How NAT traversal works
• Tailscale: Access controls
• Tailscale: MagicDNS